home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970626-19970929 / 000370_news@newsmaster….columbia.edu _Sat Sep 20 15:05:28 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id PAA06387
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 20 Sep 1997 15:05:28 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id PAA13460
  7.     for kermit.misc@watsun; Sat, 20 Sep 1997 15:05:27 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: C-Kermit Feature?
  12. Date: 20 Sep 1997 19:05:25 GMT
  13. Organization: Columbia University
  14. Lines: 18
  15. Message-ID: <6016pl$s9q$1@apakabar.cc.columbia.edu>
  16. References: <34240471.0@news.pacifier.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:7695
  19.  
  20. In article <34240471.0@news.pacifier.com>,
  21. Mike Freeman <mikef@pacifier.com> wrote:
  22. : I have encountered the following situation with C-Kermit V6.0.192:
  23. : C-Kermit's default block-check-type is 3-character-CRC.  As expected, if a
  24. : communicating Kermit cannot handle the CRC block-check-type, C-Kermit
  25. : reverts to the block-check-type the two Kermits *can* agree on.  For
  26. : example, if the other Kermit handles only the original
  27. : 1-character-checksum, C-Kermit happily accommodates it.  Problem:  after
  28. : the file transfer, C-Kermit does not restore the block-type-check to the
  29. : default 3-character-CRC.  Or at least, when does a "show protocol", the
  30. : block-check-type shows up as the one last used.  Is this intended
  31. : behavior?  I should think not.
  32. : 
  33. : I'd be interested in a patch/fix.
  34. : 
  35. It will be fixed in the next release.  Thanks for the report.
  36.  
  37. - Frank